fix(common): update TS module resolution flow#1659
Open
arturovt wants to merge 7 commits into
Open
Conversation
arturovt
force-pushed
the
fix/ts-resolution
branch
2 times, most recently
from
0de7266 to
b2a36d8
Compare
arturovt
force-pushed
the
fix/ts-resolution
branch
from
b2a36d8 to
b6737b9
Compare
Owner
|
@arturovt The CI is failing 😬. |
arturovt
force-pushed
the
fix/ts-resolution
branch
from
ea040ac to
f2d57f2
Compare
arturovt
force-pushed
the
fix/ts-resolution
branch
3 times, most recently
from
6b5ca2f to
15c4e1b
Compare
Collaborator
Author
|
Ugh that CI is so weird with random failures... doesn't even show any error... |
arturovt
force-pushed
the
fix/ts-resolution
branch
5 times, most recently
from
f9ab45e to
e02da5d
Compare
Collaborator
Author
|
@just-jeb could you run ci locally? Maybe you can see the actual error… |
Owner
|
@arturovt I'll give it a look. Were you unable to run it locally? |
arturovt
force-pushed
the
fix/ts-resolution
branch
from
e02da5d to
9aaf502
Compare
just-jeb
added
bug
This commit updates the implementation for resolving `.ts` files. Instead of registering the `ts-node` project only once, we now refrain from doing so since there might be multiple projects with different configurations. The current approach involves dynamically switching the implementation for registering and unregistering the project after the `.ts` file has been transpiled and resolved. This change addresses an issue where warnings were encountered when `ts-node` attempted to register with different configurations. The number of configurations is no longer a concern, as each time we need to read a `.ts` file, a new TS project is registered. This adjustment does not impact performance or other attributes because `ts-node` allows native project disabling. Part of the implementation has been adapted from what Nrwl Nx already has; we can find their implementation here: https://github.com/nrwl/nx/blob/master/packages/nx/src/plugins/js/utils/register.ts It's worth noting that their implementation is somewhat versatile, as it also supports SWC. Closes: #1197 Closes: #1213 Closes: #1730
just-jeb
force-pushed
the
fix/ts-resolution
branch
from
9aaf502 to
4d1acd2
Compare
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
The root tsconfig already sets module and moduleResolution to Node16. The redundant explicit settings in packages/common/tsconfig.json caused compilation failures.
- Add moduleResolution:'node' alongside module:'CommonJS' in ts-node options to fix TS5095/TS5110 when user tsconfig uses moduleResolution:'bundler' or 'Node16' (incompatible with CommonJS in transpileOnly mode) - Remove module.register(ts-node/esm) hook which caused TypeError in Angular build context
…space dep The sanity-app-esm example uses webpack-esm-plugin to test ESM imports from TypeScript webpack configs. The package only had an ESM export, so ts-node (running in CJS mode) could not require() it. Added a CJS wrapper and the require export condition, and declared the package as a file: dependency in sanity-app-esm/package.json so Yarn resolves it.
This was referenced May 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Checklist
PR Type
What is the current behavior?
When loading
.tsconfig/plugin files, ts-node is registered once per process. If two projects use different tsconfig files, the second registration is silently skipped with a warning, meaning the wrong tsconfig may be used. Additionally, registering ts-node withmodule: 'CommonJS'while the user's tsconfig specifiesmoduleResolution: 'bundler'or'Node16'caused TS5095/TS5110 errors.Closes #1197, #1213, #1730
What is the new behavior?
.tsfile load (register → require → unregister), so each load uses the correct project tsconfigmoduleResolution: 'node'is added to the ts-node compiler options override to avoid TS5095/TS5110 conflicts when users specifymoduleResolution: 'bundler'or'Node16'@angular-devkit/corelogger dependency is removed fromcommon; the logger parameter is removed fromloadModule()webpack-esm-pluginlocal package with CJS + ESM exports)Does this PR introduce a breaking change?
The
loadModule()signature change (removing theloggerparameter) is technically a breaking change for external consumers, but the logger was only used internally for the ts-node re-registration warning.Other information
Originally authored by @arturovt. Rebased and fixed to resolve CI failures (TS5095/TS5110 moduleResolution conflict, missing
webpack-esm-pluginCJS entry, removed ESM hook that caused TypeError in Angular build context).